1. Field of the Invention
The present invention relates to a system and method for authenticating a surrounding Web application (AWA) by a Web application that is to be embedded (AWB).
2. Description of the Related Art
In industrial plants, various multi-vendor systems and applications currently exist alongside one another, such as Supervisory Control and Data Acquisition (SCADA), Manufacturing Execution System (MES) or Distributed Control System (DCS) systems. Some systems in turn consist of a plurality of individual applications, e.g., for engineering and operation. Domain-agnostic applications, for example for communication, document administration/processing and navigation, are obviously also represented in such plants. The user must work across the different applications in many process steps and activities. Many of these systems are available as Web applications that are executed in a browser. Applications of this type are furthermore often integrated with one another in order to operate them via a common user interface.
The applications are often visually integrated with one another (i.e., in the presentation layer), and this applies to Web applications in particular (also known here as “mash-up” or “mashup”). The different applications furthermore develop their own user interface, which is embedded within a higher-order user interface. The details set out below address, in particular, the application authentication of applications, not the authentication of natural persons (user authentication).
Particularly in industrial plants, users/customers or system integrators often wish to combine the different Web applications with one another. However, there are various reasons that may argue against uncontrolled integration. For example, the integration of different applications may be linked to a license, but a customer/integrator does not have an adequate license for the plant. Applications may furthermore reveal sensitive data, so it should be ensured that only trusted applications can be integrated with one another.
For these reasons, the integration of Web applications into other (Web) applications is currently often prevented in principle with technical means. The most common variant in this respect is the prevention in principle of the incorporation of a Web application into other applications, such as where an application recognizes whether it is being executed in a lower-order window, known as an “inline frame” or “iframe” for short, and then refuses the execution. In addition, the use of a Web Application Programming Interface (API) is usually restricted. However, only the client, i.e., the party using an API, authenticates itself here to the API. Typical authentication methods here are API keys, client IDs, authorized URLs, or digitally signed URLs.
An API key is requested once from the API provider for each application and is attached to each request. The disadvantage is that the key is transmitted as clear text. This method is therefore used primarily for billing. Client IDs are also often used instead of a key. The implementation and disadvantages are comparable to API keys. In the case of authorized URLs, entire domains (e.g., http://example.com) are authorized with respect to the APIs that are used. When the API is called, the address of the caller is transferred and double-checked. This approach is strongly dependent on the specific installation of an infrastructure. This method is often combined with other authentication methods, e.g., client ID.
All of these methods address only API calls to a server, wherein the server does not authenticate itself to the caller.
A mutual authentication is known in HTTPS/TLS. However, only clients/servers are authenticated here. This therefore involves a security measure for the transport channel, which provides no authentication at product or application level.
Various authentication methods are similarly known that are used, inter alia, for user authentication and user authorization downstream. However, in the case of various login methods, a check is only performed to ascertain whether a user is allowed to use a specific application. No check is performed to determine whether different applications are (allowed to be) linked to one another.
Whereas numerous means are therefore available to a surrounding Web application for authenticating and therefore allowing and blocking a Web application that is to be embedded, there is a need for improvement with respect to the problem concerning the control facilities a Web application that is to be embedded has with respect to its surrounding Web application.